Conventional storage arrays store persistent data in coarse storage containers such as LUNs or file system volumes. This means that if a conventional storage array needs to apply service policies or management operations to its stored data, the array can only do so on a per-LUN/file system volume basis because the LUN/file system volume is the smallest logical unit of storage that is understood by the array. This limitation can be problematic in virtualized deployments where there is typically a many-to-one mapping between storage clients, such as a virtual machines (VMs), and LUNs/file system volumes. In these deployments, each VM may require a certain quality of service (QoS) and/or storage management operations that are specific to its data. However, since the data for multiple VMs are contained in one LUN/file system volume, the storage array cannot distinguish one VM from another and thus cannot autonomously apply storage policies/operations on a per-VM basis.
To address the foregoing, a framework has been developed (referred to herein as the “VVol” framework) that enables storage arrays to understand and manage data in the form of more granular logical storage objects known as virtual volumes. Unlike LUNs and file system volumes, each virtual volume is configured to hold the persistent data (e.g., virtual disk data, VM configuration data, etc.) for a particular VM. With this framework, the platform components in a virtualized deployment can inform a VVol-enabled storage array of service policies or management operations that are needed with respect to specific virtual volumes (and thus, specific VMs). The VVol-enabled storage array can then autonomously apply the policies or operations to the specified virtual volumes. Additional information regarding the VVol framework can be found in commonly-owned U.S. Pat. No. 8,775,774, issued Jul. 8, 2014, entitled “Management System and Methods for Object Storage System.”
Existing implementations of the VVol framework support certain VM storage management operations such as snapshotting and cloning. However, these existing implementations generally do not support the replication of a VM and its constituent virtual volumes from a first storage array/site to one or more second storage arrays/sites, or the recovery of such replicated virtual volumes at the second storage arrays/sites. Accordingly, it would be desirable to have techniques that address these particular use cases.